suggestion: these two states don't really have anything in common, and by that I mean that when you call setState, you are only really changing one or the other and not the two simultaneously. Rather than bundling them into a separate interface, it'll be easier to handle code that treats them separately.

interface Props {
  ...
  config: string;
  onCancel: () => void;
  onConfigChange: () => string;
  visible?: boolean;
}

there is another concern of passing in a function that can mutate a state of a different component directly that's not itself instead of a buffered event handler.

hmm I had it the other way first but here I'm thinking we could separate writeable states of the component into its own group as I'm anticipating we add more when we add the form on top or more features.

update: I separated the read part of the states into separate props but as we talked I left the set part of it.

I left out the part that creates another handler on top of the setState to let the interface of the setState which allows both passing the new state and a function to set the state but also lower changes to experiment details page as you already have another PR open there.

issue: TL;DR - avoid passing setState to child component and instead pass in a setState

The crux problem of this anti-pattern is that the state writing operation is in two places, the parent and the child component. The on[Action] pattern is used to keep the state and setState contained in the parent and the child modal will just send events back to the parent for it to handle the source of truth (state). It's also perfectly fine to have multiple on[Action] handler because the idea there is to orthogonalize unrelated events from each other, so the handlers do not have to worry about one event from another. This is especially important with the useCallback hook, because of the dependency list.

suggestion: separate these into two different useState. They are related in that they are both fed into the modal but that's about it. Changes in visibility and changes in config shouldn't alter each other.

I see that, I can separate them. let's chat about it. Wouldn't react be smart enough to not cause rerenders if only one of these changes? On the other hand, I remember adding each individual hook adds an extra rerender.

super nit: visible and config as alternative to arg0?